Databases contain information, commonly in a relational form that can be queried and presented to a user. Query languages were used to describe the data that was to be retrieved from a database, and also to describe how it was to be organized for viewing by a user.
Many new software applications, including databases, are written using object oriented languages. The use of object oriented languages generally results in the encapsulation of data in containers called objects, which contain data or code or a combination of both. The objects are related together in a hierarchy. The objects have a number of functions called methods that can be applied to them to manipulate the data within them or cause them to perform a function. Display objects are used to present information to a user, by receiving data from the database objects and processing it in a desired manner to provide a view of the data to a user.
In prior programs, display objects subscribed to receive change notifications from the database objects when data in the database object changed. Initially, the change notifications were very primitive, just indicating that a change had occurred. It was then up to the display object to actually generate a communication to ask the database object for the new information, or rerun the query.
Improvements to the change notifications removed the need for back and forth communications to obtain the data that changed. Newer object models include typed event services, which provide self contained update notices. Display objects, sometimes referred to as target objects are able to receive updates from source objects and immediately process the new data to update the display. In the case of a target display display object, that meant providing an updated display of the information, whether directly, or following some permutation into a desired format, such as a graphical representation.
The form of the updates is different than one would expect in prior programming environments. The updates are actually in the form of methods or functions that were applied to the source object to update the data as in the case of a database source object. Thus, the method "insert" would specify what datum to insert where in a table. The change notification then would specify the same method or an equivalent method to be applied to the target object. The target object would then perform the appropriate method or function to change its operation consistent with the change in the source object.
The use of applying equivalent methods to source and target objects works very well when there is consistency between the source and target object. When they both start in the same state, change notices work very well, as volumes of data need not be transferred or processed each time a change occurs in the source object. Only the changes need to be applied consistently to each object.
While the source and target objects have been described so far as a database and display objects, there are many different target objects in an application whose state is a function of another object or objects' states. The target objects are sometimes referred to as a view. These views allow users and applications to define their informational needs and to be notified of new or changed information that is relevant to their view of the data. The source objects may not only be databases, but other objects as well, including but not limited to objects representing live real-world entities.
One problem with the method of change notification is that new target objects or views need a way to become initialized in the correct state. The current methods of change notification provide no mechanism for this to occur. Further, there is no means of synchronizing the source and target object to ensure that they are applying changes to the same data.
Relational database management systems have implemented the concept of views for many years. Basically, a view is a derived subset of data referred to as a table. The contents of the table are defined by a query posed against other tables in the database. For example, a view can be defined as all records in a table for the month of July. Relational views were originally frozen in time. They represented that state of the database at a particular point in time. Whenever an application required the content of the view, it had to be completely recomputed from the underlying data. Techniques were developed to intercept incremental changes to the source tables and determine if they affected the content of the view. If they did, the incremental update was performed on the materialization of the view. This added significant complexity and consumed much system resource. Further, a relational database management system has trouble dealing with unstructured data such as maps, and cannot support incremental updates to the map or perform operations such as map cropping.
There is a need for a better way to track and update state changes to objects and the objects that depend on their states. There is a need to provide such a way for unstructured data, such as maps. There is a further need to synchronize related objects when one of the objects changes states and to ensure that they continue to remain synchronized. There is yet a further need to track the history of changes and to be able to traverse historical states of sets of objects. Still further, is a need to offer users flexibility in defining views which filter the massive amounts of information available into views of the data that provide them with only the information that they need.